Typical secure remote access technologies, such as IPSEC and SSL VPNs allow remote end-users to access applications and files residing in a single network behind an access gateway. Unfortunately, IT administrators often need access to different resources from distributed networks to perform their tasks.
For example, a managed service provider might maintain the Tokyo, Chicago, and London (geographically dispersed) networks of an international bank. A particular administrator working for the managed service provider may be responsible for maintaining all of the servers of a particular type across all three networks and may routinely be required to perform upgrades across those three networks at the same time.
Suppose the administrator needs to apply a patch currently located on a system in Tokyo to systems in Chicago and London. One technique is to use an IPSEC VPN gateway to bridge the three networks and create routable paths between them such that the administrator can authenticate to a single access gateway and “see” the other networks behind it. Unfortunately, by doing so a security risk is also created—the bridging of multiple networks to allow an individual to see all three networks effectively gives that user full access across the WAN. If the individual is untrustworthy, inept, or the individual's client is otherwise compromised, all three networks can now be compromised. Further, networks are increasingly intentionally segregated for reasons such as government regulations/auditing, etc. In such cases bridging multiple disjoint networks may not be possible.
Another option is for the administrator to make use of serial connections. In that scenario, the administrator would first connect to Tokyo and copy the file locally to his laptop. The administrator would then disconnect from Tokyo and connect to London, copying the file from his laptop to a node in London. After performing the updates, the administrator would disconnect from London and connect to Chicago. The administrator would again copy the file from his laptop to a node in Chicago, perform the necessary administrative tasks, and disconnect. While the Tokyo, London, and Chicago networks can remain disjoint in this scenario, the administrator is likely to spend a lot of additional overhead (e.g., in time) logging in and out of networks, copying information to and from his laptop, etc.
Therefore, it would be desirable to have a better way to connect to multiple networks.